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Amendments to the Drawings 

The attached Replacement Drawing Sheet containing Fig. 22 replaces the previously- 
filed drawing sheet containing Fig. 22 of this Application. An Annotated Drawing Sheet 
containing a marked-up version of amended Fig. 22 is also attached. 
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Remarks 

Prior to this Amendment, Claims 1-30 were pending in the present application. By this 
Amendment, Applicant has amended Claims 1, 14, 15, 16, and 28. No new matter was added by 
this Amendment. Applicant respectfully requests reexamination and reconsideration of the 
pending claims in view of the amendments and remarks contained herein. 

I. Interview Summary 

On October 24, 2007, Applicant's representative and Examiner Faber conducted an 
interview regarding the present application. During the interview, the following proposed 
amendment to claim 1 was discussed: 

1 . A method of generating a document, the method comprising: 

establishing a software architecture for a set of rules, where each rule in the set of rules is 
configured to be embedded in one or more computer processable documents, the documents consisting of a 
plurality of components, the set of rules defining content to be included in the documents;-an4 

creating a dynamic document structure that can resolve to one or more instances of a document 
and that is configured to include document content including one or more embedded rules based on the 
software architecture for the set of rules ; and 

resolving the dynamic document structure by executing the one or more embedded rules included 
in the document content . 

The Applicant asserted that the Office had misconstrued the term "rules," in essence 
adopting a definition that is inconsistent with the guidelines on claim construction set forth in the 
MPEP, which requires that any interpretation of the prior art and the claims proposed by the 
Office be reasonable and consistent with the interpretation that those skilled in the art would 
reach. See, e.g. MPEP §2111. In particular, the Applicant noted that the "rules" in the cited art, 
were simply business rules that might, for example, take the form of a written list in a document. 
Such rules might, for example, dictate the times that an employee might be required to begin 
work at an employer, describe certain procedures to be followed to perfect a security interest, or 
a variety of other regulations or requirements. However, none of these rules take the form of 
rules that are embedded in a computer processable document (as opposed to be simply existing 
as written words) and configured to be executed by a computer during the process of resolving a 
dynamic document structure that resolves to one or more instances of a document, where the 
rules determine what content is put in each instance of the document. 
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During the interview, the Examiner also indicated that the Poole reference was, in 
essence, written in a complicated fashion and difficult to understand. For the record, Applicant 
notes that its current attorney did not write the Poole patent, but the Examiner who allowed the 
Poole patent to issue deemed it to have met all the requirements of Section 1 12, by virtue of its 
issuance. Applicant also notes that one of the current co-inventors of the Poole patent is a co- 
inventor of the current application. The Applicant is familiar with the technology in the Poole 
reference and it does not disclose what has been asserted. 

No agreement was reached with the Examiner. 

II. Claim Rejections - 35 U.S.C. § 102(b) 

Claims 1, 12-13, 16-17, and 28-30 stand rejected under 35 U.S.C § 102(b), as being 
anticipated by United States Patent No. 6,006,242, issued to Poole et al. (hereinafter referred to 
as "Poole"). As discussed below in more detail, Poole does not teach or suggest the subject 
matter defined by these claims. 

According to the Office, Poole teaches establishing a software architecture for a set of 
rules to be embedded in documents that consist of a plurality of components. Applicant asserts 
that (1) the portions of Poole referenced by the Office as disclosing the above claim elements do 
not disclose establishing a software architecture for a set of rules to be embedded in documents 
and (2) Poole, taken its in entirely, does not teach or suggest establishing a software architecture 
for a set of rules to be embedded in documents where those rules define content to be included in 
the documents, as recited in amended Claim 1. 

Before further explaining the distinction between the claimed subject matter and the 
subject matter disclosed by Poole, it is useful to note that not all "rules" are the same. For 
example, in the Background of the Invention Section of Poole, the use of rules in the prior art is 
explained as follows: 

The system disclosed in Miller . . . employ[s] a conventional relational database 
scheme to test customer-specific input information against a table of rule sets which, 
in turn, are directly linked to various boilerplate clauses. A rule set is assigned to 
each insurance policy clause and each endorsement clause. The insurance and 
endorsement clauses and rule sets are stored in a memory ... . Each rule set 
includes at least one rule that must be satisfied in order to include the associated 
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clause in the document. After entering customer-specific parameters into the 
computer, . . . each and every rule in each and every rule set is evaluated to determine 
whether a particular clause is to be included in the document. In order to print a 
document, a printer database containing a redundant copy of each insurance and 
endorsement policy clause is utilized to supply the appropriate clauses .... 

Although the system disclosed in Miller provides for some degree of improvement . . 
. , there remains a . . . need ... for a flexible inferencing capability that dynamically 
determines content to be included in a document, wherein direct linkage between 
content and content determining rules is obviated. The present invention fulfills 
these and other needs. 

Thus, in Poole an improvement in dealing with rules was made by eliminating a direct 
linkage between the content and the content determining rules. The elimination of the direct link 
involved the use of catalogs. See, e.g., Abstract of Poole. In the system disclosed by Poole, a 
document developer manually specifies entity references to be included in a document based on 
the document developer's own knowledge of the business, legal, and/or governmental rules and 
regulations that govern a particular document. Col. 5, lines 1-7 of Poole. The entity references 
specified by the document developer are then resolved using catalogs. Col. 19, lines 9 of Poole. 
In particular, the document generation system disclosed in Poole attempts to find a match 
between an entity reference specified by the document developer and an entity reference 
specified in a catalog. Col. 6, lines 55-59 of Poole. Once a match is found, the entity reference 
is resolved according to the resolution strategy or process specified in the matching catalog entry 
through the use of an inference engine. Col. 6, lines 64-67 and Col. 7, line 1 of Poole. During 
the entity reference resolution process, the inference engine determines what rules apply and 
loads rules from the knowledge base. Col. 20, lines 27-36 and Col. 42, lines 44-45 of Poole. 

In contrast, the claims at issue define a different approach. At a high level, the difference 
can be stated as such, in Poole the rules are in the knowledge base, not in the actual documents. 
Thus, embodiments of the present application provide a software architecture for rules that can 
be embedded in documents. The Office cites to col. 2, lines 15-16 and 41-48, and col. 80 lines 
22-23 of Poole as disclosing a software architecture. These portions of Poole disclose, 
respectively, a system for dynamically constructing documents and the fact that software 
embodying document construction software can be stored on a CD-ROM. However, neither 
Poole as a whole or the cited section of Poole teach embedding rules in a document as claimed so 
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that the rules are executed during a resolution process performed with a computer processor with 
the result being an instance of a specific document, in accordance with, for example, claim 1 . 

Next, the Office cites to col. 5, lines 3-24, as, apparently, disclosing each rule in the set of 
rules being configured to be embedded in the documents where the rules define content to be 
included in the documents. 

If one continues beyond the portion cited by the Examiner, the Poole patent explains how 
it deals with rules and resolution. 

The block diagram of FIG. 2 illustrates one embodiment of an entity reference resolution process. 
A document developer interacts with a user interface 20 to select entity references representative 
of content to be included in a document. An unresolved entity reference 24 defined in a document 
instance 22, such as entity reference &A shown in FIG. 1, is initially compared against a Catalog 
26 containing pairs of entity identifiers and associated resolution strategies. A comparison is 
made between the name of the entity reference to be resolved and the entity identifiers 
contained in the Catalog 26. Upon a successful match, the resolution strategy associated 
with the matched entity identifier in the Catalog 28 is effectuated by use of an Inference 
Engine 28. The Inference Engine 28 resolves the entity so as to return a resolved entity 30, also 
termed a component. Other unresolved entity references 24 contained in the document instance 22 
are similarly resolved and typically organized as a linearized stream 40 of resolved entity 
references or components. Upon resolving all of the entity references contained in a document 
instance 22, a resolved document instance is thereby produced. A document of a desired structure 
and format style may then be produced as a printed or electronic document or form. 

Col. 5, lines 40-62 of Poole (emphasis added). As should be apparent, the resolution process 
involves interaction with a catalog, not with rules embedded in the document. Thus, Poole does 
not teach what Applicant has claimed. 

The Office also cites to col. 7, lines 28-60 of Poole to support its position, the cited 
portion plus the following paragraph indicates that 

Turning now to FIG. 5, there is illustrated in block diagram form a depiction illustrating the 
methodology by which a document is dynamically constructed in accordance with one 
embodiment of the present invention. A document, such as document instance- 1 62 or document 
instance-2 64, may be defined from text and graphical components accessed from a Knowledge 
Base 31. As previously mentioned, the Knowledge Base 31 further includes various 
document type definitions (DTDs), catalogs, rules, and links. In the embodiment illustrated in 
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FIG. 5, the Knowledge Base 31 is defined to include document components A through F, which, 
in turn, are linked to a business or governmental regulation source, such as regulation-Y 80 or 
regulation-Z 90. Also illustrated is a Catalog 26 within which is stored pairs of entity identifiers 
(component identifiers) and corresponding entity reference resolution strategies. Entity 1 stored in 
the Catalog 26, for example, is associated with an entity resolution strategy that is implemented by 
a Store Manager named INFENG, which is a short form of the name Inference Engine. The 
document instance-1 62 is defined to include entity references &1, &2, and &4. During the 
document construction procedure, the entity reference &1 is read from the document instance-1 62 
and compared against the entries of the Catalog 26. A match is determined between the entity 
reference &1 and the ENTITY 1 identifier stored in the Catalog 26. The reference to INFENG in 
the associated resolution strategy indicates that entity reference &1 is to be resolved by 
employment of an Inference Engine 28. The Inference Engine 28 resolves entity reference &1 to 
document component-A 66 which is linked to paragraph-1 94 of regulation Z-90. The content of 
regulation-Z 90 may then be incorporated into a final document 65 by referencing document 
component-A 66. 

By way of further example, the entity reference &2 of the document instance-1 62 is resolved by 
comparing entity reference &2 with the entity identifiers stored in the Catalog 26. Matching entity 
identifier ENTITY 2 indicates that entity reference &2 is to be resolved by implementing the Store 
Manager named FILE 54. The Store Manager FILE 54 resolves entity reference &2 by remrning 
document component-B 68 which is linked to a file containing section- 1 92 of regulation-Z 90 as. 
The content of section- 1 92 of regulation-Z 90 may then be incorporated into a final document 65 
by referencing document component-B 68. 

(emphasis added). 

As should be apparent from the above, the Knowledge Base 31 includes the rules, not the 
documents ("As previously mentioned, the Knowledge Base 31 further includes [1] various 
document type definitions (DTDs), [2] catalogs, [3] rules, and [4] links.") 

The Office also cites to col. 12, lines 10-24 and asserts that this portion discloses 
"Documents Properties that are properties of a document or rules to follow. Such properties 
(rules) include the page margins, base font, page orientation, and paper size to follow." The 
Office goes on to indicate that "these properties are embedded in the document." 

Applicant readily admits that page margins, fonts, page orientation, and paper size are 
old. Applicant also admits that one might properly refer to margins, fonts, page orientation, and 
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paper size as document "properties." However, it requires a complete distortion of the teachings 
of Poole and a large leap in logic to equate the actual margins, fonts, page orientation, and paper 
size, which are admittedly inherent in things properly characterized as a "document," with 
"rules," particularly when 1) the words "property" and "rule" are not synonyms and 2) Poole 
itself describes its own "rules" in a different manner. 

Regarding the Office's equation of the words "property" and "rule," the word "property" 
generally refers to an attribute or quality of a thing. In contrast, the word "rule" generally refers 
to a principle or prescription that governs action. It is improper to use these terms 
interchangeably because they clearly have different meanings. A thing may possess a property 
after a rule has been applied, but something that has a property does not necessarily possess a 
rule. Thus, documents that inherently possess properties such as margins, do NOT inherently 
possess rules. 

Regarding the rules described in Poole, as noted above and as shown in Fig. 19, the rules 
used in Poole's document generation system are stored in the knowledge base. As explained by 
Poole, 

[t]he dataflow diagram of FIG. 19 shows the Inference Engine Processor 300 as a 
single process that takes an initial request from an Application 301 to begin 
processing, and makes periodic requests to the Application 301 and Knowledge Base 
302 to complete its task. In FIG. 20, there is depicted the basic processes associated 
with the operations of the Inference Engine 300. The Inference Engine 300 consists 
of three main processes. The Application Interface 304 takes a name that 
corresponds both to a text file containing the rules to execute and passes that name 
along to the Parser 306. The Parser 306 reads the text file and converts the text into 
an executable Rule Network 305 that is returned to the controlling Application 
Interface 304. The Rule Name 307 to execute and the Rule Network 305 are then 
passed to the Evaluate Rule Processor 309, which begins evaluating rules in the Rule 
Network 305 beginning with the rule corresponding to Rule Name 307. 

Col. 42, lines 46-62. 

Clearly, Poole discloses storing rules in the knowledge base 1 and makes no mention 
whatsoever that the rules are embedded in a document. 



See also, "'Knowledge Base* is a term that refers to a collection of documents, document components, document 
type definitions, catalogs, rules, and links. Col. 4, lines 54-56 (emphasis added); "As is indicated at step 101, 
knowledge is entered into the Knowledge Base in the form of documents, document components, document type 
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Returning to the rejections presented by the Office, the Office first cites portions of col. 5 
of Poole as disclosing "establishing a software architecture for a set of rules." The portions of 
col. 5 of Poole cited by the Office, however, only disclose manual specification or selection of 
content based on an individual's personal understanding and application of business, legal, or 
governmental rules, NOT a software architecture for a set of rules. 

Second, the Office cites portions of col. 12 of Poole as teaching "establishing a software 
architecture for a set of rules to be embedded in documents." Again these portions merely 
disclose a document developer manually specifying desired copy setup, margins, paper size, etc. 
through a dialog box 270 (shown in Fig. 17), and make no mention of the application of rules or 
where such rules are stored. 

Applicant also notes that Poole notifies a user if document properties entered by the user 
via the dialogs are compliant with document regulations. Col. 12, lines 19-21. As a 
consequence, the rules would need to be accessible and executable at the time the user enters the 
document properties, most likely by the dialog itself, in order to provide error checking in a real- 
time or near real-time fashion. Therefore, the rules governing compliant document properties 
would not be embedded in a document. In addition, all rules disclosed in Poole are stored in the 
knowledge base, and Poole does not teach that rules are embedded in the documents produced by 
the document generating system. 

Therefore, Poole does not teach or suggest embedding rules in documents and embedding 
error-checking rules defined in Poole in a document created by the document generation system 
disclosed in Poole would not be inherent or obvious, since the rules would need to be executed 
by the dialogs presented to the user. 

In addition, Poole does not teach or suggest "creating a dynamic document structure that 
can resolve to one or more instances of a document and that is configured to include one or more 
embedded rules based on the architecture for a set of rules," as recited in amended Claim 1 . As 

definitions, catalogs, rules, links, and other information needed to construct any number of document and form 
types." Col. 6, lines 17-22 (emphasis added); "Knowledge is preferably entered into the Knowledge Base by a 
domain expert who is experienced in some field of domain of human knowledge. At step 103, the knowledge is 
entered into the Knowledge Base in units of text or text fragments referred to herein as components. At step 105, 
the rules that dictate the access and utilization of components are also entered into the Knowledge Base." Col. 6, 
lines 29-35 (emphasis added). 
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disclosed in Poole, after the document developer selects the appropriate entity references, "the 
resolved . . . [entities (not rules) are] returned and made available for incorporation into a 
document in the form of a corresponding document component" (col. 7, lines 10-14). In 
addition, Poole discloses that a "significant advantage of the document construction 
methodology illustrate in FIG. 1 concerns the ability to integrate components selected from the 
stream 40 of components into SGML documents of varying types and styles. Document-X 44, 
for example, is shown as having been constructed using resolved and validated components A, 
B, C, and N in accordance with a first document structure and format style. Document-Y 46 and 
Document-Z 48 are shown as having been constructed using the same components A, B, C, and 
N to produce documents having differing structures and format styles. It is noted that other 
documents can be constructed using one or more of the components A, B, C, and N. It can be 
seen that any number of documents can produced with desired structural and stylistic 
requirements, and published in printed or electronic form" (col. 5, lines 25-39). 

As further disclosed in Poole, "[i]t is noted that the format style of the document, as well 
as any of the document components corresponding to the resolved entity references, is typically 
determined after completing the resolution process, but may alternatively be determined during 
the resolution process" (col. 7, lines 17-22). 

Therefore, although the resolved components can be manually or automatically formatted 
and/or incorporated into one or more documents based on a document structure or form, Poole 
does not teach or suggest that the resolved components or the documents that will contain the 
resolved components include embedded rules. In fact, embedding rules in the resolved 
components would cause the components to be considered "unresolved," since they would not be 
useable in a document in their present form (e.g., additional processing would be necessary to 
resolve the rules). In addition, as noted above, since Poole does not disclose establishing a 
software architecture for a set of rules to be embedded in documents that define content to be 
included in documents, Poole clearly does not teach or suggest creating a structure that includes 
rules based on the architecture for a set of rules. 

In summary, Poole does not teach or suggest "establishing a software architecture for a 
set of rules, where each rule in the set of rules is configured to be embedded in one or more 
computer-processable documents, the documents consisting of a plurality of components, the set 
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of rules defining content to be included in each instance of the one or more computer- 
processable documents," as recited in amended Claim 1 . Poole also does not teach or suggest 
"creating a dynamic document structure that resolves to one or more instances of a document and 
that is configured to include document content including one or more embedded rules based on 
the architecture for a set of rules," as recited in amended Claim 1 . Accordingly, for at least the 
reasons set out above, independent Claim 1 is allowable and dependent Claims 2-13, which 
depend from independent Claim 1, are also allowable. 

B. Independent Claim 16 

As described above with respect to Claim 1 , Poole does not teach or suggest establishing 
a software architecture for a set of rules configured to be embedded in documents, where the 
documents consist of a plurality of components, the set of rules defining content to be included 
in documents. Therefore, Poole does not teach or suggest "retrieving one or more cross- 
referenced document components from a data base, the one or more document components 
configured to include document content, one or more embedded rules, the one or more embedded 
rules defining content to be included in documents" as recited in amended Claim 16. 

Furthermore, as noted, Poole actually discloses storing document components in a 
knowledge base separate from rules that are also stored in the knowledge base. In particular, 
Poole discloses that "at step 103, the knowledge is entered into the Knowledge Base in units of 
text or text fragments referred to as components. At step 105, the rules that dictate the access 
and utilization of components are also entered into the Knowledge Base" (col. 6, lines 31-35). 
Therefore, although Poole discloses using rules during the resolution process in order to 
determine document components, Poole does not teach or suggest retrieving document 
components that include embedded rules from a knowledge base. Storing rules in a knowledge 
base that also stores document components is not equivalent to embedding rules in document 
components and then storing the document components in a knowledge base. Therefore, Poole, 
among other elements, does not teach or suggest "retrieving one or more cross-referenced 
document components from a data base based on the transaction data set, the one or more 
document components configured to include one or more embedded rules, the one or more rules 
defining content to be included in documents," as recited in amended Claim 16. 
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Accordingly, for at least the reasons set out above, independent Claim 16 is allowable 
and dependent Claims 17-27, which depend from independent Claim 16, are also allowable. 
Similar rationale can be applied to independent Claim 28, as amended, and the claims that 
depend on Claim 28. Therefore, Claims 28-30 are allowable for at least one or more of the 
reasons set forth above with respect to Claim 16. 

III. Claims Rejections - 35 U.S.C. § 103(a) 

Claims 2-11, 14-15, 18-27 stand rejected under 35 U.S.C. § 103(a) as being unpatentable 
over Poole in further view of printed publication "XML in a Nutshell" authored by Harold et al. 
(hereinafter referred to as "Harold"). 

A. Independent Claims 14 and 15 

Claims 14 and 15 recite, inter alia: 

A method of generating a document, the method comprising: 

establishing a software architecture for a set of rules configured to be 
embedded in documents by creating a schema having a conditions element, a 
choose element, an iterators element, a functions element, and an external 
interface element that is configured to be resolved into a value, the set of rules 
defining content to be included in documents; . . . 

As described above with respect to Claim 1, among other elements, Poole does not teach 
or suggest establishing a software architecture for a set of rules to be embedded in documents 
wherein the set of rules define content to be included in documents. Harold does not cure the 
deficiencies of Poole. In contrast, Harold merely discloses standard elements and functions 
associated with the extensible markup language ("XML"). Although Harold may disclose 
means for establishing an architecture for a set of rules (e.g., the architecture may be based on 
XML), Harold makes no mention whatsoever of establishing an architecture for a set of rules, 
wherein the rules are to be embedded in documents and define content to be included in 
documents. Therefore, independent Claims 14 and 15 are allowable for at least the additional 
reasons set forth above. 

B. Dependent Claim 2-11 and 18-27 
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Dependent Claims 2-11 and 18-27 depend from independent Claims 1 and 16 
respectively and, therefore, are allowable for at least the reasons set forth above with respect to 
Claims 1 and 16. Nonetheless, Applicant provides additional explanation regarding the 
allowability of these claims. 

As noted above, Poole does not teach or suggest establishing a software architecture for a 
set of rules to be embedded in documents where the rules define content to be included in 
documents or "creating a dynamic document structure that can resolve to one or more instances 
of a document and that is configured to include one or more rules based on the architecture for a 
set of rules," as recited in amended Claim 1. As also noted above with respect to Claim 16, 
Poole does not teach or suggest "retrieving one or more cross-referenced document components 
from a data, the one or more document components configured to include one or more embedded 
rules, the one or more embedded rules defining content to be included in documents" as recited 
in amended Claim 16. Harold does not cure the deficiencies of Poole. As described above with 
respect to Claims 14 and 15, Harold does not teach or suggest establishing a software 
architecture for a set of rules, wherein the rules are to be embedded in documents and define 
content to be included in documents. In contrast, Harold merely discloses standard elements and 
functions associated with the extensible markup language ("XML"). Therefore, Claims 2-1 1 and 
1 8-27 are allowable for at least the additional reasons set forth above. 

V. Response to Examiner's Comments 

The Examiner equates a document construction methodology to an architecture. This is a 
distortion of the word "architecture." An architecture is a physical design, like the architecture 
of a building, the architecture of a software program, or the architecture of a data structure. And 
in claim 1, for example, the architecture is for the set of rules, not the document. (Claim 1 reads, 
in relevant part, "establishing a software architecture for a set of rules."). Thus, constructing a 
document is not the same as defining an architecture for a set of rules. 

Regarding the comments that the rules in Poole are embedded in the document, it simply 
amazes the Applicant that the Office continues to interpret Poole in this fashion when the explicit 
statements of Poole indicates that the rules are in the Knowledge base. In fact, despite assertions 
to the contrary, the Office admits that Poole store its rules in the knowledge base, not in the 
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documents. The Examiner states, "In addition, the Knowledge Base includes rules being stored." 
Page 13 of the Office Action Dated May 3, 2007. The Office continues to rely on the fact that 
Poole mentions that document developers develop content to meet rules (such as rules published 
by the government). However, Poole's statement simply means that content can be developed to 
comply with general rules such as government rules, NOT that the general rules are embedded in 
a document. If anything, what gets placed in the document by the developer or author is the 
content. The rule is lost when the author makes the determination. For example, for purposes of 
addressing the Examiner's arguments only, consider a hypothetical scenario where a general rule 
is SLOPE = mX + B. If an author complies with the rule, SLOPE gets put in the document. 
However and in direct contradiction to the Examiner's assertion, since the rule is complied with, 
the rule does not get put in the document. There's no need for it. 

The claimed subject matter does not require (or at least diminishes) the need to have a 
human author or developer pick and chose what content to include in an instance of a document. 
And, as already noted, the Applicant is not claiming general rules in the abstract. Rather the 
applicant is claiming, as in claim 1, for example, a software-architecture for a set of rules, where 
each rule is configured to be embedded in one or more computer-processable documents, where 
the rules determine what content gets put in a document, and are resolved or executed to create 
an instance of a document. 

Regarding claims 12-14, the Examiner asserts that the features relied upon are not in the 
claims. Claim 14 has been amended to include the term "embedded." Further, as noted above, 
the Office is required to interpret the claims in a reasonable manner. MPEP §2111. So, while 
limitations of the specification are not to be read into the claims, the claims can NOT be read in a 
vacuum either. 

Regarding the comments on page 13 of the May 3 rd Office Action, the Office cites to col. 
7, lines 31-40 and lines 28-60 and col. 5 lines 3-34 of Poole. The Office asserts that these 
sections teach that the document components are linked to regulations and that the content of the 
regulation is included in a final document. The Office concludes that the regulations are rules 
which are "embedded" in the document. Assuming, only for the sake of argument, that the 
Office is correct in its assertions about the teachings of Poole, what the Office essentially 
contends is that any document that includes a list of rules has rules embedded in it in the context 
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of the claimed subject matter. This is incorrect. Admittedly, Pooles does state that "[t]he 
Inference Engine 28 resolves entity reference &1 to document component- A 66 which is linked 
to paragraph-1 94 of regulation Z-90. The content of regulation-Z 90 may then be incorporated 
into a final document 65 by referencing document component-A 66." Col. 7, lines 58-60 of 
Poole. But in this case, regulation 90 (just like any document with a list of general rules) is 
simply part of the final content of the document. The regulation does not determine what 
content is included in the document, by for example, a resolution process, as claimed, for 
example, in claim 1. 

V. Conclusion 

In light of the above, Applicant believes that the application is in condition for allowance 
and respectfully requests that a timely Notice of Allowance be issued in this case. Applicant also 
requests that the Examiner telephone the attorneys of record in the event a telephone discussion 
would be helpful in advancing the prosecution of the present application. 

Charge or credit Deposit Account No. 1 3-3080 with any shortage or overpayment of the 
above fee. 
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